1. Field of the Invention
The present invention pertains to the Internet. More particularly, this invention relates to an improved request acceptor for a server application system that allows early prioritization and adapted processing of requests accessing the server application, and a method thereof.
2. Description of the Related Art
With the rapid growth of the Internet, more and more business and residential users are beginning to rely on the Internet for their mainstream and mission-critical activities. As is known, the Internet typically refers to a number of data service systems connected together via a high speed interconnect network (see FIG. 1). Each data service system typically includes Internet server applications that host content for various customers. The Internet server applications can also host applications. Remote user terminals (e.g., terminals 11a-11n in FIG. 1) may be connected to a data service system (e.g., the data service system 20 in FIG. 1) via an interconnect network. Each user terminal is equipped with a web browser (or other software such as an e-mail software) that allows the user terminal to access the content and/or applications hosted in various data service systems.
Popular Internet applications include World Wide Web (WWW), E-mail, news, and FTP applications. All of these applications follow the client-server model and rely on the Transmission Control Protocol (TCP) for reliable delivery of information/applications between severs and user terminals. These applications can also be referred to as server applications. A user can access a server application (e.g., web server) by generating at least one request to the corresponding server application. The server application then services the request. A server application can be accessed by multiple users at the same time. The server application typically handles the user access requests in a first-in-first-out (FIFO) fashion.
One problem of the above-identified prior art server application is that it does not have protection mechanism against excessive load conditions. Another problem is that the server application does not provide performance guarantees to its customers that host their content/service sites in the server application. To overcome these problems, prior proposals have been made to add quality-of-service (QoS) middleware in the server application. FIG. 2 illustrates one such prior proposal. As can be seen from FIG. 2, the QoS middleware 32 includes a session manager 40, a classification module 41, and an admission control module 42. The session manager 40 determines whether an incoming request is part of an existing session or not. The classification module 41 then associates the request with a class. If the request is part of an existing session, the classification module 41 associates the request with a premium class. If not, the classification module 41 associates the request with a basic class. The premium requests are sent to a premium queue in the priority queues 43 while the basic requests are sent to a basic queue in the priority queues 43. This allows the middleware 32 to offer differential treatment for existing session requests relative to new session requests. Following classification, the admission control module 42 determines whether a basic request should be admitted for service or rejected before it is sent to the priority queues 43.
Disadvantages are, however, still associated with this prior approach. One disadvantage is that the processing of the session manager 40 and the classification module 41 is still done in a FIFO manner (i.e., sequential processing). This makes those premium requests to wait in the middleware until they are processed. The differential treatment offered by the middleware 32 is effective only after the requests have been inserted into the priority queues 43. This means that the middleware 32 may still become a bottleneck in terms of processing the incoming requests. The middleware 32 becomes a bottleneck when it is receiving a large number of requests. If it becomes the bottleneck, the middleware 32 is not able to offer differential service because of its use of FIFO scheduling.
Another disadvantage is that manual configuration and tuning of the middleware and/or the server application is typically required to ensure optimal performance. This is a significant task for the operator of the server application because many of the settings require in-depth understanding of the structure and operation of the server application, as well as that of the middleware. For example, the operator has to specify parameters such as the maximum lengths of the priority queues in the middleware 32. Even the admission control criteria (e.g., CPU utilization, queue length, etc.) has to be specified by the operator. In addition, the optimal values of these parameters are also different for different workloads of the server application. Thus, the operator may need to constantly tune the parameters manually to ensure optimal performance since the workloads change from time to time.
One feature of the present invention is to allow early prioritization of the incoming requests in a server application system.
Another feature of the present invention is to allow adapted processing of classified requests in a server application system.
A further feature of the present invention is to provide means in a server application system for allowing early prioritization and adaptive processing of incoming requests.
An acceptor for admitting incoming requests to a server application includes a session manager that determines the class of an incoming request. The class includes a first class and a second class. A queuing module is provided to store the request if the incoming request is of the second class. A priority control module is provided to ensure that a predetermined number of requests are sent to the server application for service in each cycle. The priority control module allows (1) the predetermined number of the first class requests to be sent to the server application if the first class requests received in a cycle are at least equal to the predetermined number, and (2) a mixture of the first class requests and the second class requests to be sent to the server application if the first class requests received in a cycle are less than the predetermined number.
A method of admitting incoming requests to a server application includes the step of determining the class of an incoming request. The class includes a first class and a second class. The request is stored in a queuing module if the incoming request is of the second class. A predetermined number of the first class requests are sent to the server application if at least the predetermined number of the first class requests are received in a cycle. If the number of the first class requests received in a cycle is less than the predetermined number, then a mixture of the first class and second class requests equal to the predetermined number are sent to the server application.
Other features and advantages of the present invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.